Operation of a video production switcher can be very complex, as there are often a large number of resources which are set to specific states to create a desired on-air effect. Thus, recreating an effect manually can be a time-consuming and error-prone task. Switchers often provide effects memories, as disclosed in U.S. Pat. No. 4,205,344, for example. An effects memory (or “memory” or “E-Mem” as it is also known), is a snapshot of the state of resources within an entire switcher or a defined subset of those resources, and may be considered a form of a video state or a “look” of a video output and/or audio output or “program”.
Prior implementations of memories, as well as timelines and macros, are very useful tools to a user, allowing many complex video operations to be simplified into a small number of simple actions by the user. However, these tools tend not to be very flexible.
When a memory is recalled, it will completely replace the state of resources in the switcher or the subset of the switcher to which it has been recalled. This will remove any elements that were currently set up, either on-air or off-air, and replace them with those elements defined in the memory, affecting their on-air state. This is undesirable if a user wishes to recall a memory and then cleanly transition (using, for example, a dissolve, wipe or DVE effect) to the new settings. Current settings are instead instantaneously changed to the recalled settings.
Although a user may, in some switchers, set memory attributes to selectively recall desired subsets of a switcher or Multi-Level Effects device (MLE), the user must anticipate which resources are available at the time the memory, macro, or timeline is created. For example, if a user is currently using a chroma key on key 1, and wishes to recall another effect using a memory, the user must have previously built the effect into a memory on a keyer other than key 1, and set the appropriate memory attributes to recall the memory only to the previously-determined keyer. This is undesirable, for several reasons. First, it requires the user to anticipate which keyer may be available at recall time when the user is building and storing the memory. Secondly, it requires the user manually set attributes to control the specific subset of the switcher to recall. Thirdly, it does not allow for the user to preview the recalled memory before recalling it to air. Fourthly, some implementations map specific resources to fixed visual layers, wherein, for example, an element on key 2 always appears on top of an element on key 1. Selectively recalling using a memory attribute is limited in that the layering priority cannot be manipulated in the process of recalling the memory to a subset of the switcher, so the desired layering priority may not be achieved.
Some implementations allow effects stored in one MLE to be recalled to a different MLE, as disclosed in U.S. Pat. No. 6,437,831, for example. This can, in a limited fashion, allow a user to recall an effect which can be previewed on the switcher prior to bringing it on-air. However, this is limiting in that complete MLE banks must be recalled, and the user must pre-select which MLE will be used to recall the effect. Furthermore, this approach requires multiple MLE banks to perform this action. Since an MLE often employs multiple resources to create a complex effect, this approach is unsuitable when a smaller subset of resources is required, as the user must recall the inter-related resources to an MLE.
A further limitation of current video switcher technology is that small systems may have only 1 MLE and a memory recall will instantly replace all settings on the switcher. If the user wishes to perform a dynamic effect to transition from the previous state to the state defined within the memory, then they will be unable to do this. The method disclosed in U.S. Pat. No. 6,437,831 cannot be applied to a system having only 1 MLE.
Although “recall to preview” does, in some limited situations, allow a memory to be recalled to a subset of the switcher without disturbing the on-air output, it still requires the user to anticipate which resources will be available when the memory is recalled. Recall to preview will not recall the states of any resources that are on-air in the switcher state prior to the recall, so if the desired switcher memory uses, for example, key 1 when key 1 is already on-air, the state of key 1 will not be recalled. In this example, the user would have had to anticipate that key 1 would have been in use and stored the effect using a different keyer. Recall to preview also requires the user to anticipate how they wish to transition from the on-air state to the state recalled in the memory. The user must either program this into the memory or manually manipulate the transition controls on the control panel to cleanly transition to the newly recalled state.